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[57] 



ABSTRACT 



A method and apparatus for creating, supporting and 
using a "travelling program" is disclosed. A "travelling 
program" is a digital data structure which includes a 
sequence of instructions and associated data and which 
has the capability of determining at least one next desti- 
nation or recipient for receiving the travelling program 
and for transmitting itself together with all relevant data 
determined by the program to the next recipient or 
destination. The travelling program can compute, ac- 
cording to any algorithm, the digital material which is 
to be signed, and also, as needed, the digital material 
which is to be verified. The program can conditionally 
decide, based on any known criteria, which users 
should participate in the signature process. Digital sig- 
natures allow the travelling program to provide other 
types , of valuable authentication. The travelling pro- 
gram operates to automate data collection among a 
group of users. It can be sent to one user, attach (or 
detach) relevant data files and move on to the next user. 
Data or files, collected from one or more users can be 
deposited with another user, or accumulated for 
batched processing as desired. This methodology elimi- 
nates the need for individual users to be counted on to 
transmit all the required data in the required format. 
The present invention also efficiently performs elec- 
tronic. data interchange (EDI) in the context of a travel- 
ling program which sends itself from user to the next 
within an organization, collecting, editing and approv- 
ing data. 

26 Claims, 29 Drawing Sheets 
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tabic, the actual digital material which is signed is en- 

MEfflOD AND APPARATUS FOR CREATING, tirely different 
SUPPORTING, AND USING TRAVELLING * It is anticipated that the type of digital signature de- 

PROGRAMS scribed above may be applied to data construction 

5 which will have a long life—and perhaps be verified by 
This is a continuation of application Ser. No. different entities over a period of time. In the case of 
07/863,552 filed Apr. 6, 1992, now abandoned. EDI, for example, the signatures can be bound to the 

FIELD OF THE INVENTION transaction itself, and may be verified by any fu- 

ture recipients of that transaction, even outside the 
The present mvention relates to a method and appara- 10 context of the travelling program. This type of digital 
tus for creating a ^travelling" program which has the signature is analogous to a hand-written signature 
capability of movmg itself together with necessary asso- ^h appears at the bottom of a paper purchase order 

elated data from one computer user to another to contract 

thereby create a powerful tool for processing, authenti. ^^i^ition to being able to sign arbitrary data, the 

catmg, and coUectmg data at vanous computer nodes. 15 present invention also allows the program to condition- 
BACKGROUND AND SUMMARY OF THE decide, based on any known criteria, which users 

INVENTION should participate in the signature process. 

. . ^ , ^ „ For example, with the present invention, the travel- 

Withjn organization, documents are often moved ^ ^ ^3^^ j,,^^ determinations, within 

manuaUy. A mad or deUvery service is often employed 20 ^ ^ ^^^t coWure requirements may 

when documents are required to be transmitted be- fwT «Ilf;.*«i«, a^*» ^™u;««*;«/ 

tween organizations particular data, user, or some combination. 

T I, ' f I ' * • 11 J * This can include information contained in a user*sX. 500 

Techmques for dectromcaUy transnuttmg docmnents certificate, or enhanced digital certificate (e.g., as ac- 
within an organization and between orsanizations are ^^-^^ ^iti««iw« ^^uiiiv^vt y^^.^.j « «v 

well known. Tlie rapid growth of electronic mail sys! 25 fl^^'^ mventor's U S. Pat. Nos. 4,868,877 or 
terns, electronic tr^sfer systems and the like have 5,005,200)^Because complete programmatic flexi^^ 
served to automate certain business transactions and ^^^s, such extracted mformation can even be used to 
eliminate some of the manual document transfers that ^^^^ transmission route for the traveling 

are in most instances unnecessary. program. . ^. . , , ^ . , 

One prior art methodology for automatically trans- 30 J"" addition to usmg digital signatures for smiple au- 
ferring information between users (for example, within thentication. the present invention also allows authonty 
an organization) utilizes a soncalled -electronic forms" requirement and uses to be mcluded and venfied as 
methodology. This "electronic form" methodology ^^^^ ^P°"' example, the teachings of 

presents data to a user, solicits the user's input via a 4,868,877 and 5,005,200 to control au- 

conventional display, verifies that the input data has 35 thority proof and ddegatiori. . , , 

been correcdy entered, and thereafter transmits such ^« ^^^^^ ^^d' ^he present mvcntion also allows 

data to another user, digital signatures to allow the travelling program 

The electronic form methodology is very limited in *o provide other types of valuable authentication. For 
many respects. For example, if the data represents any example, as a security convenience the present inven- 
value, then there is always the potential danger that 40 tion allows for the digital signature authentication of the 
data could be manipulated or altered, or simply created entire transmission from one user to another. This m- 
bogusly. Attempts to address this danger have involved eludes the travefling program itself, its variables, and 
flagging certain critical fields which are to be digitally ancillary data or files. 

signed. This allows acertain limited amount of authenti- ™s second type of digital authentication differs 
cation for specific input fields, exactly as they were 45 fr*™ data-oriented authentication described above, 
entered. ^ ^ carries long-term significance— since 

However, it does not permit complex data structures variables and other data which are transmitted will 

to be assembled and then digitaUy signed. The present changed once the receiving user has taken any action 

invention allows for the travelling program to compute, all. This second type of authentication is therefore 

according to any algorithm whatsoever, the digital 50 primarily seen as a protection against tampering, and 
material which is to be signed, and also, as needed, the can also be used forensically as a backward audit to 
digital material which is to be verified. detect unauthorized tampering even by one of the ac- 

Thus, for example, the present invention allows the tual users of the form, 
actual data which is signed to be different than any field ^ addition, the present invention also provides a 
data itself. In fact, it is possible that the signed material 55 third type of authentication, whereby the travelling 
contains none of the actual data as presented by the program itself may be signed, authenticated and autho- 
user. rized by some trusted issuing authority (e.g., perhaps 

An example, of one way this is especially usefiil is the author), to insure that no bugs or 'Viruses'* have 
when the travelling program of the present invention been introduced. (This even protects against infection 
creates an EDI (electronic data interchange) transac- 60 by a user which has valid possession of the program 
tion based on aspects of the entered data^ The program along the route). 

has the ability to sign the EDI transaction. Such EDI The present invention provides a iinique mechanism 
transactions may well be composed of complex digital for automating data collection among a group of users, 
information which was looked-up, based on internal The travelling program may be sent to one user, attach 
tables within the program, firom other tabular files, or 65 (or detach) relevant data files and move on to the next 
from the supervisor or interpreter which drives the user. Data or files, collected fi-om one or more users can 
travelling program. Thus, input fields which may have be deposited with another user, or accumulated for 
been simply entered as "X"s which selected from some hatched processing as desired. This methodology elimi- 
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nates the need for individual users to be counted on to FIGS. IS and 19 delineate the sequence of operations 

transmit all the required data in the required format performed for executing external functions or calls; 

The present invention also efficiently performs dec- FIGS. 20 and 21 delineate the operations which are 

tronic document interchange (EDI) in the context of a performed when a travelling program mails itself to a 

travelling program which sends itself from user to to 5 predetermined recipient; 

the next within an organization, collecting, editing and FIG. 22 delineates the sequence of operations for 

approving data. At the appropriate point, as determined attaching a file to the travelling program; 

by the program's logic, it is then able to programmati- FIG, 23 shows how a file may be erased from a user's 

cally. generate a standard EDI transaction (e.g., such as system; 

the X 12 850 Purchase Order Transaction set) for trans- 10 FIG. 24 shows the sequence of operations performed 

mission- to another organization.. The travelling pro- in detaching a file from a travelling program; 

gram is able to digitally sign the finished transaction set. FIG. 25 delineates the sequence of operations per- 

Accordingly, any receiving organization which can formed when a file has been transformed into a user file; 

process the standardized EDI, and the standardized FIG. 26 delineates the sequence of operation per- 

signature wHl be able to authenticate and process the formed when material is to be digitally signed; 

incoming material, even if the receiving organization FIG. 27 delineate the sequence of operation per- 

does not have all the powerful techniques available formed by a "INTER-ROLLOUT" function; 

which are taught by the present invention. FIG. 28 shows the sequence of operations performed 

Conversely, the present invention allows a travelling when displaying information to the user; 

program to receive ordinary EDI transaction, possibly FIG. 29 delineates the sequence of operation per- 

signed, and allows them to be parsed and incorporated formed by the "time delay" routine; 

into its variables. The travelling program then has the FIG. 30 shows the sequence of operations for a "se- 

capability of validating the input and incorporating lect from directory" function; 

them into displays, and to move them among various FIG. 31 is a routine which demonstrates how the the 

recipients as necessary. interpreter program permits a user to perform digital 

BRIEF DESCRIPTION OF THE DRAWINGS , « u 

FIG. 32 exemplifies how a user verifies received 

These as well as other features of this invention will information; 

be better appreciated by reading the following descrip- FIG. 33 illustrates how a travelling program collects 

tion of the preferred embodiment of the present inven- a file to be transferred; 

tion taken in conjunction with the accompanying draw- FIG. 34 illustrates the travelling program operations 

ings of which: performed in reading data from a specified file; 

FIG. 1 is a block diagram of a communication system FIG. 35 illustrates how the travelling program may 

in accordance with an exemplary embodiment of the 35 update or create a file from program variables; 

present invention; FIG. 36 illustrates how a travelling program may be 

FIG. 2 shows an exemplary structure of a travelling designed to be spht and send programs to a number of 

program together with its associated components; different recipients; 

FIG. 3 shows an exemplary execution control area FIG. 37 demonstrates how previotisly spht programs 

data structure; ^ may be merged; 

FIG. 4 shows the data structure of a file control block FIG. 38 shows an alternative approach to merging 

(FCB) which is used when a travelling program at- previously split travelling program information; 

Uches files to. or detaches files from itself; FIG. 39 is a flowchart indicating how the travelling 

FIG. 5 shows a process control block that is utilized program has been designed to accommodate electronic 

in the execution of a travelling program; 45 document interchange generation functions; and 

FIG. 6 illustrates a variable control block data struc- FIG. 40 relates to the use of travelling program m 

ture (VCB) which is used for controlling variables; receiving an electronic data interchange transaction. 

FIG. 7 shows an exemplary travelline proeram 

loader, ^ h e DETAILED DESCRIPTION OF THE 

FIG. 8 shows how the header is loaded; 50 PREFERRED EMBODIMENT 

FIG. 9 shows how the "program" segment of the FIG. 1 shows a block diagram showing an exemplary 

travelling program is loaded; communication system which may be used in conjunct 

FIG. 10 shows how the "variables" segment of the tion with the present invention. This system includes a 

travelling program is loaded; communication channel 12 over which communication 

FIG. 11 shows how the "certificate" segment of the 55 between terminals A, B, . . . N, may take place. Commu- 

travelling program is loaded; nication channel 12 may, for example, be ain unsecured 

FIG. 12 shows how the "file** segment of the travel- communications channel such as a telephone line, 

ling program is loaded; Terminals, A, B . . . N may, by way of example only, 

FIG. 13 delineates how the "closure" segment of the be IBM PC compatible computers, having a processor 

travelling program is loaded; ^ (with main memory) which is coupled to a conventional 

FIG. 14 represents the operations performed in pro- keyboard/CRT display 4. The processor with main 

cessing P-code instructions; memory 2 is also coupled to a non-volatile storage 

FIG. 15 shows processing which takes place after the which may be a disk memory. Each terminal, A, B . . . 

P-code operation is performed; N also includes a conventional IBM PC communica- 

FIGS. 16A and 16B show processing, for handling 65 tions board (not shown) which, when coupled to a 

program defined functions or calls; conventional modem (6, 8, 10, respectively), permits a 

FIG. 17 shows the sequence of operations for han- terminal to transmit and receive messages including 

dling built-in fimctions; travelling programs. 
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As used herein, a "travelling program" is a digital for any reason to recompute any material to be verified, 

data structure which includes a sequence of instructions and to perform a digital signature verification, 

and associated data and which has the capabihty of The results of such verification can be annoimced to 

determining at least one next destination or recipient for any recipient, or more likely, the travelling program 

receiving the travelling program and for transmitting 5 can simply perform the verification and announce a 

itself together with all relevant data determined by the problem should there be a failure (which suggests at- 

program to the next recipient or destination. tempted data tampering). 

Each terminal is capable of generating a message and Because the travelling program monitor may embody 

performing whatever digital signature operations may the teachings of U.S. Pat Nos. 4,868,877 and 5,005,200, 

be required to load and execute the logic, data, and 1° ^ possible for authorization to also be checked so that 

functions inherent within the travelling program (as recipient can be assured that the necessary authori- 

described more fully herein), and transmitting the mes- zations were performed. 

sage to other terminals connected to communication After a particular data structure has been constructed 

channel 12 (or to a communications network (not and signed under control of the travelling program, it is 

shown) which may be connected to a communication possible to subsequently reconstruct that data structure 

channel 12). to provide its signature to any other entity. Such 

The digital signature and certification methodology ^ subsequently tampered by any entity, 

described in the inventor's U.S. Pat. Nos. 4,868,877 and However, the present invention also embodies capa- 

5.005,200, as well as 5,001,752 may be used herein, bility whereby all the transmitted data is digitally signed 

which patents are hereby expressly incorporated herein 20 as it is sent from one user to the next The travelling 

by reference. Alternatively, more conventional digital Program processor m the recipient's computer can auto- 

signature methodology may be utilized. matically verify this signature as the traveUing program 

Before describing the details of the "travelling pro- '"^ assures that no component whatsoever is 

gram" structure and methodology in accordance with "^^'^^ tsmpezed along the way. While this overaU 

an illustrative embodiment of the present invention, an signature only refiects the state of the data during this 

example of the general operation in an actual business P^^^,^ transmission, and hasno sigmficance for later 

transaction contlxt wUl be briefiy described. Initially, T^v /"^"^^^ ^"^^ transmission untampered 

presmne that the user of the FIG. 1 terminal A is a ^^^^ P'^^^^ ^ ^^"^"^^ ^"^^^ 

1 . 1 1 X ^JL * . * u^uiuAot -f^ » mechanism if it is necessary to trace covert tamoerine 

rekuydylowlevd^ 30 by participating users^^e tSoSuse^S 

eammacorporationseekmgtoobtamcomponentparts of ^e forii.xL overall signature differs from current 

to complete a circuit desi^ project capabilities whereby electronic mail is signed, in that 

The engineer usmg keyboard 4 would access a parts ^ ^ conditionally induced by the trav- 
requisition ^veiling program'' of the type to be de- elling program itself, as part ofthe transmission process, 
scnbed m detail below. The reqmsmon "travelhng pro- 35 ultimately, after all the approvals have been obtained 
gram wiU prompt the cngmeer to descnbe the compo- ^^^1^ organizational structure, the travelling pro- 
neat parts needed. The travelling program includes an ^^^^ ^ p^^l^^^^ O,^^, 
mstruction sequence which will automaticaUy transmit This could be done in many ways. It may weU be 
itselftoanextd^totion,e.g.,toa8upervisorwhohas possible for a travelHng program to support several 
accesstoterminalBandwhoishigherupmtheorgam- 40 methods, choosing the one most appropriate for a given 
zational structure and possesses the authority to ap- circumstance. We describe four possibilities here: 
prove the requisition request and digitally sign it The 1, The travelling program could simply print out the 
travelling program may also transmit ancillary informa- fj^al purchase order on paper— possibly even print- 
tion, such as fdes wMch may be necessary or useful at the company logo, letterhead, etc.-which 
future destmations. The supervisor will be prompted to 45 would be physically mailed, 
properly digitally sign the request. It is possible that the 2. The travelling program, if <^upled with an outgo- 
digital signature reflects not only specific variables val- ing computer-to-fax capability, could automati- 
ues, but also the variable names. Alternatively, the sig- cally generate a purchase order image, that would 
nature may also reflect some aggregate structure which appear on the vendor's fax machine. The buyer 
is derived from variables computed within the program, 50 vvould not have to produce paper, 
wherein the values may be based on any of many 3. if it is known that the vendor also supports the 
sources, includmg data read from file, user input, data travelling program methodology of the present 
built into the program, various signer's certificates, or invention, then it is possible that the travelling 
data which is extracted from the user environment program will simply designate the vendor as a next 
(such as the user's ID), etc. . 55 destination. 

If tile request is approved, the requisition form will 4. It is also very possible that the vendor does not use 

take a different patii in the organization then if it is not the present invention, or that the purchaser's trav- 

approved. The travelling program can have the intelli- elling program cannot determine with certainty 

gence to determine, based upon the input from the su- that the vendor is able to handle the travelling 

pervisor at the operating terminal B, where to transmit 60 program methodology. 

itself within the organization. The travelling program Therefore, the travelling program manipulates its 

will also, if desired, load the memory associated with mtemal data to construct a standardized EDI (Elec- 

terminal B with the appropriate . data relating to the tronic Data Interchange) transaction, which can be 

requisition and to attach if desired any files from termi- widely recognized and processed. The travelling pro- 

nal B that needs to be forwarded elsewhere in the orga- 65 gram may also cause a digital signature to be performed 

nization. on the computer EDI transaction, and the signature and 

Once a signature has been done, the travelling pro- the transaction can both be transmitted. The travelling 

gram has the ability at any later time, for any later user, program would then transmit the EDI transaction, as 
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well as any possible signature, to the recipient. (Such for example, relate to a purchase order related applica- 
transmission is independent of, and should not be con- tion. 

fused with, the transmission of the travelling program The travelling program will possess the characteris- 
and its ensemble from user to user as part of its directed tics described above including the ability to transmit 
travels.) 5 itself to farther recipients. Thus, program 22 will in- 

. Any recipient that can handle standardi2ed EDI elude instructions for forwarding itself via whatever 
transactions is then able to handle the received EDI medium is available to one or more recipients. This is 
input Any recipient that can handle digital signatures, known herein as a "traversal". One source code instruc- 
is further able to authenticate the transaction. Further- tion or several P-code instructions may be required to 
more, provided the recipient has sufficient software 10 result in the "traversal" of the travelling program to one 
capability to recognize them, the recipient can also or more identified recipient(s). The travelling program 
automatically validate any authorization that may be structure set forth in FIG. 2 is designed to be indepen- 
embodied as part of the signature. It is up to the logic of dent of any particular computer architecture and is 
the travelling program the extent to which certificates structured in accordance with international standards 
should be transnaitted along with a signed transaction, 15 (e,g., X.209 format). 

In any of the above cases, the travelling program can The travelling program also includes a "variables 
spin off the purchase order (P.O.) information to the segment" 24. Prior to being executed by a first user, the 
vendor, using any of several possible levels of automa- variable segment 24 may be virtually empty. Once the 
tion. Following this, the travelling program might program is sent to a recipient, further variables will 
transmit one version of itself, or possibly just a letter, 20 become defmed as they are required by the program to 
back to the originator, to inform him that the P.O. has thereby result in an increasing number of variables as 
been sent Other information can be sent to an archive, the program is further executed. By way of example 
or to a queue to await further processing. This informa- only, the variable section 24 may identify a variable, 
tion could be a simple message, a record added to a file, such as "totaLdoUars.received'* together with an actual 
or perhaps the travelling program schedules a full tra- 25 data value for this variable. 

versal (automatic "mailing" or transmission). Each variable may have associated therewith the 

FIG. 2 illustrates the structure of a travelling pro- information set forth in each of the fields 32-42 shown 
gram together with its associated components in accor- in FIG. 2. Field 32 identifies the size of the variable 
dance with an exemplary embodiment of the present name. The variable name itself is stored in field 34. The 
invention. The FIG. 2 travelling program includes at 30 size of the value of the variable is set forth in field 36. 
least the following multi-field segments. A first header The value of the variable is in field 38. Field 40 identi- 
segment 20 preferably identifies the size of each of the fies the execution stack level to which the variable 
component segments, the name of the associated pro- belongs. The execution stack level is identified since the 
gram (and possibly other segments described below), same variable name can exist at different levels within a 
thedate, the type of each component (e.g., the program 35 program (e.g., one variable name noiay exist in a first 
is the source language program, or the program is P- subroutine while the same variable name may exist in a 
code that has already been compiled), the identity of the separate or nested subroutine and yet have a different 
form, version of the interpreter needed to execute it, defmition). The execution stack level is helpful in recon- 
data necessary to resume execution at the appropriate structing the travelling program in a recipient's com- 
point of program resumption (such as execution stacks, 40 puter to take on the same logical structure it had in the 
PCBs, etc.), dates associated .with the latest traversal, sender's computer. Field 42 is an optional field which 
and program authorization information (PAI). Each may identify a type of variable, e.g., strings, octets, 
segment in the travelling program structure may in- integers, etc. 

elude its own description so that the "type of each com- The "variables" section 24 may also include a digital 
ponent and size" field "S" would not be included in the 45 signature of the respective variables and related mfor- 
header segment 20. For the purposes of the present mation. Thus, it is also possible for one or more vari- 
application, program authorization information (PAI) ables to reflect digital signatures which have been taken 
]nay be regarded as security information which defines at various times during the travelling program's execu- 
the range of operations that the associated program is tion path. One of the significant aspects of the current 
permitted to perform (e.g., defining access to files, the 50 invention is that the travelling program can create a 
ability to call programs, abihty to generate electronic digital signature on any type of information. This signa- 
mail, ability to transmit data to other users, ability to ture is itself carried as a variable. To verify the signature 
release documents, ability to execute machine language it is necessary for the program io indicate (or possibly 
programs, ability to access, special areas of memory, re-compute) the exact value which was signed, and then 
ability to display information to users, ability to soUcit 55 pass that, together with the signature value (also indi- 
digital signatures, ability to access a digital notary pub- cated by a variable) to the VERIFYSIGNATURE 
lie device, etc.). Further details regarding the nature function of the travelling program. By including a digi- 
and use of the program authorization information may tal signature of variables, a recipient will be enabled to 
be found in applicants application Ser. No. 07/883,868. verify that the data I) has not been tampered with, 2) 
entitied, "Computer System Method and Apparatus 60 has been validly signed, and 3) the signer was properly 
Using Program Authorization Information". The authorized. See above identified U.S. Pat No. 
header segnient 20 may also include a version number 5,005,200, which describes a preferred mechanism for 
of the associated travelling program. associating authority with a digital signature. 

The travellmg program code 22 segment follows the A segment 26 is shown in FIG. 2 for optionally in- 
header in the exemplary embodiment and preferably is 65 eluding with the travelling program, certificates associ- 
written in the restructured external execution program- ated with any digital signatures so that any signatures 
ming language (e.g., the R£XX language) or something may be verified by a recipient as described, for example, 
akin to PASCAL or COBOL, the program itself may, in die above-identified U.S. Pat No. 5,005,200. Altema- 
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tively, the certificates could be included in the "van- taches files to. or detaches files from itself. The file 

ables" section together with the digital signatures, control block includes a tag field 116 which identifies a 

Segments 2SA-28N contain file images that are re- tag for referencing a particular file to be attached or 

corded and tagged by name to enable the travelling detached in a particular user's system. The file control 

program to attach and store a file belonging to a travel- 5 block also includes a segment 110 which is a pointer to 

ling program user. Thereafter, the user's file may be the next file control block. The file control block also 

transmitted along with other prior user's files with the includes a status segment 112 which defines various 

travelling program. The name of the file faciUtates later status conditions such as whether the associated file has 

accessing of the fde by a user and permits the travelling just been attached by the received traveDing program; 

program user to identify any file which is. for example, 10 whether the file can be detached on the next traversal 

to be fiuther transmitted, or which is to be deposited (i.e., next mailing); whether the file has been exported 

with a particular user under particular circumstances. (i.e., the associated file image has already been loaded 

The travelling program also includes a "closure seg- into a separate user file); and an indicator as to the "type 

ment" 30 which includes, for example, the digital signa- of file" such as whether the file is stream oriented or 

ture of the entire travellmg structure so that the recipi- 15 record oriented. Other attributes of the file may be 

ent can verify that the transmiission of the entire travel- defined in this field. 

ling structure has not been tampered with since it was Segment 114 stores an indication as to the file's posi- 

last sent tion within the main incoming travelling program file so 

Having described the travelling program data struc- that the particular file in question may be quickly ac- 

turc. we now describe the data structures utilized dur- 20 cessed. Segment 118 identifies whether the local name 

ing the execution ofa travelling program and the associ- of the file (i.e., the file name identified by the most 

ated software for executing the travelling program. An recent recipient of the travelling program). The local 

execution control area (XCA) data structure is shown in name of the file is typically provided if the file has been 

FIG. 3. The XCA specifies information required by the attached and is being forwarded to a further recipient or 

program which executes the travelling program, once 25 if an already attached file is being "exported", i.e., 

the travelling program has been received by a recipient, stored locally by a particular user. Additionally, as 

and compiled into P-code (unless it was originally trans- shown in FIG. 4, the FCB may contain a hash of the 

mitted in P-code). associated file. As will be appreciated by those skilled in 

As shown in FIG. 3. XCA segment 82 identifies.the art, a hash is a "one way" fimction which should be 

address and size of the program as it appeared in the 30 computationally easy to compute given the underlying 

incoming file. It should be recognized that, throughout data. The hash fimction should be computationally im- 

this description, whenever a segment is stated as storing possible given a hash value, to either determine the 

an "address" or "location", that the data may be aphys- underlying data, or to create any data which has the 

ical or logical address and need not necessarily directly specified value as its hash. For aD practical purposes, 

specify an actual physical memory location. The pro- 35 the value obtained from applying a hashing fimction to 

gram may be received in source or P-code and an indi- the original aggregation of data is an unforgeable 

cation is maintained as to which is the case. The execu- unique fingerprint of the original data. If the original 

tion control area includes a segment 84 which is indica- data is changed in any manner, the hash of such modi- 

tive of the address of the p-code version of the program fied data will be different 

and its size. The address (or pointer to the address) of 40 FIG. 5 shows an exemplary program control block 

the current program control block is identified in seg- that may be used during the execution of the travelling 

ment 86, The location of the list of file control blocks program, A program control block keeps track of con- 

(FCB) which is used, for example, to attach and detach trol information regarding the program being executed 

files associated with the travelling program is set forth in a structured programming context where one routine 

in segment 88. The address of the certificate control 45 calls another routine, each routine having an associated 

area (CCA) which is used for controlling certificates program control block. 

which are attached to the travelling program is set forth The program control block segment 50 points to the 

in segment 90. The location of the "variable" informa- prior program control block in the program execution 

tion table (VIT) is set forth in segment 92 which con- control stack. The program control block includes a 

trols and maintains variables in the form of a "B-tree", 50 segment 52 which defines the next P-code position to be 

which is a hierarchical binary tree structure which executed in the current executing program and segment 

identifies the location of each program "variable". 54 defines the type of last P-code operation performed. 

The execution control area also includes a security Segment 56 includes a pointer to an expression evalua- 
information segment 94 which may be used for verify- tion stack which is used during expression evaluation, 
ing the authenticity and the authority implicit in the 55 The execution stack is typically distinct from the pro- 
travelling program. Segment 96 defmes the name of the gram stack, in that the execution stack is used for evalu- 
file that contains the incoming travelling program ating expressions and keeping track of internal state, 
which may need to be accessed. Segment 98 keeps track Segment 58 defines the level of this stacking program 
of the number of times the program has mailed itself and segment 60 defines a pointer to a list of shared 
along the incoming path. The execution control area 60 variables. In the REXX language an "exposed" state- 
also includes an input parameter section 100, whereby ment may be used for accessing shared variables, 
parameters relating to the execution of the program FIG. 6 illustrates a variable control block data struc- 
may be identified. Execution control area segment 102 ture (VCB) which is used for controlling variables, 
identifies the input header information received from Segment 62 identifies where in the B-tree a variable is 
the travelling program file so that the header informa- 65 located and may contain several pointers. Segment 64 
tion vwD be available. identifies the size of tiie variable value and segment 66 

FIG. 4 shows the data structjire of a fde control block identifies a pointer to where the value is located in 

(FCB) which is used when a travelling program at- memory. Segment 68 may be optionally used to identify 
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the type of variable. Segment 70 identifies which level 
of the travelling program the variable is associated 
with, so that after the program is executed, any local 
variable which was associated with the program may be 
readily deleted. Segments 76 and 80 identify the size of 5 
the variable name and the name, respectively. 

We now turn to illustratmg the execution of the trav- 
elling program. The sequence of operations performed : 
by a "loader" portion of an interpreter execution-driv- 
ing program is set forth in FIGS. 7-12. These opera- 10 
tions relate to preparing to execute a traveUing pro- 
gram. 

A travelling program may execute in one of a plural-, 
ity of different modes such as an interactive user mode, 
a mode in which it is called by another program, or a 15 
batch operation mode in whiclx it is sent from node to 
node collecting infonnation. Initialization information 
is input diiring the start-up operation (120) to identify . 
the particular operating mode as well as associated 
run-time parameters. 20 

The flowcharts set forth in FIGS. 7-12 illustrate how 
a travelling program structure shown in FIG. 2 is 
loaded. In loading the travelling program, the inter- 
preter creates the execution control areia XCA and 
initial program control block PCB. It saves access to 25 
input parameters, saves the names of the input files that 
it has been given to load and initializes the variable 
information table (VIT) (122). In flowchart block 122, 
the execution control area and program control block 
associated with the travelling program are estabUshed. 30 
The various XCA and PCB fields are filled in during 
subsequent processing. 

Thereafter, the loader begms loading travelling pro- 
gram segments, i.e., header, program, variables, certifi- 
cates, file and closure segments as shown in FIG. 2. 35 
Loading each of the travelling program segments de- 
scribed above, e.g., header program, etc., causes appro- 
priate data to be filled in as described below. 

In block 124, a decision is made as to whether more 
segments need to be processed. If so, then the initial 40 
input is read for that segment and the type of segment is 
determined after which segment processing is initiated 
depending upon the type of segment (126). 

Turning to the header processing of FIG. 8, initially, 
a check is made to determine whether the segment 45 
being processed is the fu-st segment (150). If not, then an 
error condition exists (152) since the header must be the 
first segment. If the first segment is being processed, 
then the header is read and hashed The header data is 
stored into the XCA (154). 50 

The routine then branches back to FIG. 7 at entry 
point L. The loader determines whether there are any 
more segments to be processed (124). If so, block 126 is 
executed to result in the processing of the "program" 
segment as shown in FIG. 9. Initially, a check is made to 55 
determine whether there is a header, and no program 
has yet been loaded (160). If the answer is no, then an 
error condition exists (162). If the answer is yes, then 
the program is read and a hash is taken (164). 

Thereafter, the program hash and/or digital signa- 60 
tures associated with the program (and/or the header) 
are verified 166, If the digital signatures were not prop- 
erly authorized or could not be verified, then an error 
condition results 166. If verification occurs, then any 
security and authorization information associated with 65 
the travelling program is saved (170). Such authoriza- 
tion information could altenjatively. be kept in the 
header or in the program segment. 
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In block 172, a check is made to determine whether 
the program has been sent as P-code. If source code 
rather than P-code has been sent, then the source code 
is compiled into P-code using conventional compiler 
techniques known to those skilled in the art and the 
source code image is deleted from storage 174. Regard- 
less of the check at block 172, the position in the incom- 
mg file of the program — whether it is in source or P- 
code format— is saved m the XCA. Knowing the loca- 
tion and extent of the incoming image simplifies the 
copying of the program into eventual outbound traver- 
sal(s). Finally, regardless of whether the P-code was 
just compiled, or whether it was read form the incom- 
ing file, (he main storage address and size of the P-code 
is set into the execution control area (XCA) in 178, after 
which the routine shown in FIG. 7 is reentered at block 
124 to thereby result in loading remaining segments 
such as the "variable" segment processing shown in 
FIG. 10. 

In processing the "variable" segment as indicated in 
block 190, a check is made to determine whether the 
header and program have been loaded but no prior 
variables. If this is not the case, then an error condition 
results 192. If a header and program have been loaded, 
but no prior variables, then we begin an iterate process 
to read all the variables, if any. A check is made at 194 
to determine whether there are (more) variables to read. 
If there are more variables to read, then for each vari- 
able, a variable control block (V CB) is created as shown 
in FIG. 6 and is completed by the insertion of a variable 
identifier and value into the variable control block 
(V CB) and the setting of certain status conditions in the 
VCB. Additionally, the variable control block is added 
to the proper spot in the variable information table 
(VIT), the table which contains all program variables 
(196). 

Additionally, other variable information, for exam- 
ple, related to previous executions of the travelling 
program are loaded into memory stacks or program 
control blocks as appropriate 198. Alternatively, it may 
be desirable to keep such "control" information in the 
header segment rather than here. Thereafter, the rou- 
tine branches back to block 194, where checks are made 
to determine whether more variables are required to be 
read. The processing continues until no more variables 
need to be read, at which point the routine branches 
back to block 124 of FIG. 7 to thereby result in loading 
the next segment. 

As indicated in FIG. 11, each certificate is read (200) 
and a certificate element is created which is then added 
to a certificate control area (CCA) in storage (202). As 
schematically indicated in FIG. 11, the process is re- 
peated until all certificates are received at which point 
the routine branches back to block 124 to check for any 
more segments. 

Alternatively, it may be desirable to transmit the 
certificate segment ahead of the program segment, so 
that certificates used as part of program authentication- 
/authorization can be maintained together with any 
certificates used by program variables and user-to-user 
authentication. 

This branching operation results in the "file" segment 
processing shown in FIG. 12. Smce the file segments 
typically follow the "variable" segments, a check is 
made to determine whether the variable segment (even 
if null) has already been loaded. If not, then an error has 
been detected and an appropriate error message is gen- 
erated 212. If the "variable" segment has already been 
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loaded, then as indicated in block 214, a check is made 
to determine whether the file tag associated with the file 
has already been loaded. If so, Sien an error is detected 
indicating that the file has been duplicated 216. 

If the file tag has not already been loaded, then as 5 
indicated in block 218, a file control block is built for the 
file, the tag name is set, other status indicators are set 
that may have already been associated with the travel- 
ling program, and the file position is set relative to the 
incoming file. 10 

Thereafter, the file is read and its hash is computed 
and saved in segment 115 of the FCB. The size of the 
file is saved in segment 114 of the FCB. The file need 
not be loaded into memory at this time (220). Thereaf- 
ter, the file control block which has been created is 15 
added to the file control block list collected in the XCA 
and the routine branches back to block 124 to process 
the next segment (probably "closure"). 

In the "closure" processing in FIG. 13, the hash is 
computed of all previous hashes for each previous seg- 20 
ment (230). It should be recognized that all the "seg- 
ment" material is read subject to hashing. A check is 
then made in block 232 to determine whether the hash 
taken and calculated in 230 matches the bash added 
when the travelling program was sent (which is stored 25 
in the closure segment). If there is no match, then an 
error condition results 234, 

If there is a match, a check is made as to whether the 
travelling program is signed (236). If not, then as sug- 
gested at block 238, an action is taken to incorporate 30 
whatever level of security is desired, such as possibly 
presenting a notification that the transmission data is not 
entirely signed (238). 

If the transmission was signed, then the signature is 
verified and a message is presented to the user to accu- 35 
rately identify the party who actually sent the travelling 
program (and the associated purchase order or other 
form) 240. The routine then branches back to block 124 
of FIG. 7, 

The completion of the "closure" processing in FIG. 40 
13 results in block 124 determining that there are not 
more segments to be proc^sed. Thereafter, a check is 
made to determine whether closure was successfully 
received and processed (128). If it was not, then the 
routine stops execution after performing an unsuccess- 45 
ful validity check (130) and processing halts 132. 

If the check at block 128 reveals that closure was 
successfully completed, then various steps are taken to 
prepare for program execution (134). In this regard, 
stacks are restored, the variable information table and 50 
variable control blocks are restored. The program con- 
trol blocks are restored such that they contain the exe- 
cution resumption point. 

Thereafter, the routine shown in FIG, 14 is initiated 
to actually process the P-code instructions. The follow- 55 
ing problem must be considered here. Because the pro- 
gram execution is effectively restored identically to the 
state it was at the time it was transmitted (as part of the 
traversal) from the sender's machine, there is an issue of 
how the travelling program can distinguish whether it is 60 
in the sending machine, and just returned from the send- 
ing itself; or whether it has just been restored in the 
recipient machine. 

llie present invention allows multiple ways to ad- 
dress this problem. If the traversal ftmction is imple- 65 
mented as a built-in function, then the mterpreter will 
return a special value (say "0") to the program after it 
has successfully sent itself, and another value (say "1") 
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to the program when its execution is restored on the 
recipient's machine. The traveUing program can then 
test this value to distinguish the situation. Another way 
this distinction could be made is by providing the trav- 
elling program a function to extract the "number of 
prior traversals" (segment 98 in the XCA). Before in- 
voking the traversal, the program could use this func- 
tion to save the prior-traversal-count function. If it 
matches the value of the variable, then the program 
knows the execution is resuming in the sender's com- 
puter; if it differs (and it should only be one greater), 
then the program knows the execution is resuming at 
the recipient's computer. 

When the first user generates the travelling program, 
the loader routine shown in FIG. 7-13 is executed with 
very few, perhaps no, variables, files, or certificates. 
Accordingly, certain of the above-described steps will 
be omitted during the initial processing. The loader 
routine is executed whether the travelling program is 
executed for the first time or executed by further recipi- 
ents. 

FIG. 14 illustrates the operations performed in pro- 
cessing P-code instructions; it is repeated for every 
P-code instruction executed. As mdicated in block 250, 
the location of the next P-code instruction is derived 
from the current PCB (52), and this becomes the "cur- 
rent" F-code operation. In block 252, the length of this 
P-code operation is deteriouned, and the "next P-code" 
position (52) is updated to reflect the subsequent P-code 
instruction. The type of the current P-code operation is 
saved in (54) (It is useful for the interpreter to share 
common routines which have slight variations based on 
the precise operation. For example, the "call" operation 
and the "function invocation" operation are similar 
except that the function invocation expects a parameter 
to be returned). 

Thereafter, as illustrated in block 254, the indicated 
P-code operation is performed. Most P-code functions 
involve data manipulation, logical tests and program 
flow control By way of example only, such P-code 
operations may include locating a variable and pushing 
the variable in a stack, resetting the next P-code opera- 
tion to thereby change the fiow of control such as 
would occur in a branching operation, performing an 
arithmetic or string operation, performing IF/THEN- 
/ELSE operation based on the popped stack value, 
perform DO/ITERATEAJNTIL/WHILE, or other 
operations based on stack values, performing SE- 
LECT/WHEN/OTHERWISE operations based on 
the stack values, performing an "END" operation to 
close a DO/WHEN/SELECT operation. 

We will soon discuss in some detail various P-code 
operations pertinent to the present invention's unique 
operation. With the guidance given herein, the P-code 
functions can be implemented in a straight-forward 
manner by anyone familiar with writing interpreters. 

However, ignoring for the moment the details of the 
particular P-code function, the preferred design allows 
for P-code operations to generate logical "interrupts" at 
their completion. 

These dlow processing P-code processing to be sus- 
pended while some other, external operation must be 
perfonned. This interrupt concept is used in the pre- 
ferred design to facilitate the rollout of working storage 
whenever lengthy waits or external activity is invoked. 

In FIG. 15, on return from the P-code routine in 
block 256, the interpreter determines whether the rou- 
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tine has signaled a logical interrupt If not, then return is stack, the VIT, the XCA, the P-^ode itself, and any 

made to 250 to handle the next P-code operation. other blocks, to some auxiliary storage (such as a file). 

If an interrupt was indicated, a special check in block The interpreter itself may be released from storage, and 

258 is made to determine whether, this, is the special this may be done in a special block (264), provided that 

"EXIT' request. If so, then aU resources which should 5 sufficient residual program and data remains to later 

be released at the end of this program, such as storage, reload the interpreter and the working storage, 

mes, vanables. load subroutines, etc., are discarded in in step 266, the inter-roUout routine is invoked. Typi- 

block 260, A possible return value from the P-code cally, this routine waits for the user to enter input, or to 

operation, which may have been saved by 260, is re- wait untU a future time or other event, or to invoke 

turned m block 259 to the invoker of this travelling 10 another program which might wait for input, or cause 

program. ^ , . , , delays, or require a large of storage which is 

Assmmng, this is not EXIT, then block 261 deter- vacated by the ROLLOUT 

mines whether ROLLOUT should be performed. For ^ y,^^^^ 268, after the inter-roUout is finished, the 

example, m certam enviromnents it is useful for work- interpreter is reloaded, then the working storage, in- 

mg storage to be roUed out while a user completes 15 ^i^^ing the P-code, the execution stack, all <i,i;trol 

entering input, or while the traveUmg program is wait- ^j^^ks are restored from auxiliary storage, 

mg for a dme interval to ^ir^ or whfle alengthy (or TTien in block 270, any final processing^ done to tidy 

large) external program has been mvoked from the „ ^ ^ c f*"^»=»"^5 ^ 

* ir 1 - ^. . , . up the operation. For examole. this typically mclndes 

travelling program logic, or while the digital signature ^ . ^ ^ \ ^yy* y ^ ^ 

^^,.ti^^ Kli«tr«^^^„fo^Vo;«^^ ft ^. 7^'"*"'"'^ copymg a result returned by the mter-rollout routme to 

K^utme IS bemg executed (smce that often mvolves user 20 the execution stack, or to a program "variable". 

Routines which cause a P-code interrupt and a possi- ,„™f ^^^fi'^i ^""^Znl ^ J^'M"' 

ble ROLLOUT, regardless of whether they are imple- (2^>* ^^^^^ 

mented as built-in functions or as language statements '^ert P-code instruction is processed. 

(with their own P-code), include: 25 ^ examme some P-code operations of mterest. 

SIGN-which applies a digital signature to any com- "^^T.^^ '""^t ^^^""^ embodiment handles 

puter data, and in doing so may soHcit the user to 5^^.? function: to routmes which are 

select from multiple certificates, and solicit the user ^"^^'^ mterpreter. to routines which are writ- 

to provide his secret password key which allows the ^^t^ ^® travelling program, and to routines 

private signature key to be decrypted and used; 30 ^^^^ external to the interpreter or program, and 

DISPLAY— compose and output a screen and wait for dynamically located and invoked when the 

the user to supply input; program is executed. 

TIMEWATT— suspend execution until a future time is ^^^^ ^'^ buDt-in function appears 

reached; rather simple, and the interpreter simply locates the 

SELECT.FROM.DIRECTORY— which allows se- 35 specified function based on an index in the P-code, and 
lection from, e.g., a directory of users, or a directory lookups the routine's address (within the interpreter), 
of files, etc; calls it. However, it is important to realize that, 

NOTARIZE— wait for a time notary device to apply ™*^st do not, some built-in functions might signal 

its own digital signature. * P-code interrupt. In this case, the built-in function 

In some environments. ROLLOUT is pointless, and 40 provide the necessary pre-rollout, inter-rollout 

in these cases the rollout and rollin processes in block post-wait routines. 

262, 264, 268 will be absent or inhibited. The P-code interpreter always distinguishes CALL 

In any case, a P-code operation which signals an functions, and provides for the return of a result to 

"interrupt" also supplies the address of at least associ- execution stack in and only in the case of a function. 

ated ("call-back") functions 45 For example, the SIGN function returns a value which 

the pre-roUout routine, which performs any required represents the digital signature computed on the sup- 
functions in preparation for rollout. This might pli^d data. 

include preparing a parm field in temporary stor- ^ FIG. 16A we see that a call/function to a program 
age to pass to . . . routine causes the creation of a new PCB execution 

the inter-roUout routine which executes after as much SO level 300. The new PCB is set to start executing at the 
working storage as possible has been rolled out to start of the subroutine, by setting the next-P-code in- 
auxiliary storage; struction (52) to the P-code entry point of the routine, 
the post-wait routine which handles details following The first instruction of the routine will be accessed 
the rollback after the inter-roHout routine is fin- when block 250 is reentered. Parameters are prepared 
ished, and after working storage has been restored 55 for the program routine, appropriate status condition 
from auxiliary. Typically, this involves copying a are set, the program level 58 in die PCB is set to one 
result value computed by the inter-rollout routine higher than the calling program and the PCB is placed 
which is left in temporary storage, and which must at the top of the execution stack as the now current 
be loaded onto the execution or copied into a pro- PCB (82). The result of a program routine is passed to 
gram variable. 60 the caller through the P-code RETURN operation. 
In block 261, the pre-rollout routine is invoked. This In FIG. 16B, we see how the corresponding program 
may be a null routine, or it may setup, e.g., parameters RETURN P-code operation operates. Block 1200 de- 
fer the inter-rollout routine. termines if a RETURN is made from the highest (only) 
In block 262, the rollout function is performed, if level PCB, in which case this operates as an EXIT, and 
appropriate given the environment and circumstances. 65 block 1204 signals that a P-code "EXIT* interrupt is 
If done, then ROLLOUT consists of writing all work- required and passes the return RESULT (if any) as the 
ing storage, including the VCBs and their values, the value to eventually be returned by block 261 (FIG. 15) 
FCBs, the certificates and the CCA, the execution as the RESULT for the entire program. 
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Otherwise, in block 1204, detennination is made as to It is possible that the external routine is actually an- 

whcther the invoker used a CALL or function (e.g., by other travelling program. If so, then special optimiza- 

checking field 54 in the caller's PCB), and in the latter tion may be performed by using the existing already- 

case block 1206 puts the return VALUE on the stack loaded image of the P-code interpreter, and simply 
(or creates a default value if the RETURN had no oper- 5 passing a new set of parameters to block 120 (FIG. 7). 

and). In this, special logic would need to be inserted in blocks 

In block 1208, the current level is cleaned-up, and all 262 and 264 to conditionally avoid releasing the inter- 
resources, including storage, files, variables, etc private preter code itself. 

to this subroutine (aka "program level") are released. Now let us turn out attention to various special built- 
Resources, such as variables which are shared with the 10 in functions which are used by the present embodiment, 

caller are NOT released and are available. Many of these could be executed either as built-in func- 

In block 1210, the current PCB is then released so or as language statements with their own special 

that the caller's PCB now becomes the current one, and P-code operation. 

return is made to block 256 where execution resumes. FIGS. 20 and 21 illustrate the operations which are 

The interpreter includes built in routines which are performed when a travelling program transmits itself to 

designed to accomplbh specialized travelling program ^ predetermined recipient. In block 398, any program 

related functions relating to providing digital signa- authorizing information is first checked to insure that 

tures, user files to the travelling program and other ^® traversal operation is permitted. (It is conceivable 

functions to eliminate the need for a travelling program ^^^^ travelling programs may not be permitted to 

designer to be concerned with programming such func- ^ — ^P^^ ^^^^ function which termi- 

tjQjjg nates at the first use). In the rare case that the program 

P-code operations may also involve the performance ^ *^ * ^P^^^^ P^^" 

of a RETURN function which will affect program en^ to the caller. ^ „^ . 

control, a PROC operation which relates to a program P'*^^^ embodiment unplements the TRA- 

control block. The interpreter also performs a DIS- ^ VERSE operataon as a built-m fimc^^^^ 
PLAY operation which utilizes the interactive display "^l °" 'V "^f immediate 

«to♦>l,^/^n^«««/lo.t«,o«^ ^^.c^r^k^^ u^^^-^ Tu-. 0^ function and "1" to the caller after the 

.w^^^^ ^- ; is restarted on the recipient's computer. As 

preter also perforins a TRAVEpE o^^^^^ which j^^^ ^j. ^ ^ P ^^^^ ^P^ ^^^^ 

results m the mailmg of the traveUmg program to 3^ ^h^ program to differentiate between the sender's and 

another recipient as well as all associated data. recioienf s comoutcr 

FIG. 18 illustrates an exemplary the sequence of ^o do this, in block Z99, the TRAVERSE function 

operaUo^ performed for executmg external functions ^j,^ ^.j^^ «i„ execution stack, 

or c^s. Such external functions or caUs are not built m ^hat the stack is transmitted intact. This is the 

to the mterpreter or part of the traveUing program but 33 ^^^^ ^hat will therefore be returned when the travel- 

^ther are part of the user^s program hbrary. The named ^ ^ reconstituted and restarted on the recip- 

function or call is located from any of several possible i^nf s computer. Then all relevant variable data such as 
Ubranes 354. ^ . .the "variable" information table, process control 

A check u then made to determme if the program is ijjocks, the various stacks, variable control blocks are 

found 356. If the program is not found, then a check 40 collected into a transmission format such as a format 

may, if desired, be made to determine whether the pro- shown in FIG. 2. 

gram should be terminated or some default action be ^ indicated at block 402, the travelling program 

performed 358. If a decision is made to terminate, then header is constructed and transmitted. The travelling 

an error message is generated, and after various program is transmitted segment by segment, although it 

housekeeping/cleanup operations arc performed as de- 45 could, in fact, be transmitted in a field by field format, 

scribed above the program is exited (360, 362). or any other way if desired. Preferably, a hash is taken 

If the check at block 358 indicates that a default ac- of each segment as it is transmitted, 

tion should be taken, then the default action is taken, Thereafter, in 404, the program and any authorizing 

e.g., by returning a special default function value (368) information from the input file received with the travel- 

and the routine branches back to node O in FIG. 14 to 50 ling program is then copied to the output transmission 

begin executing further P-code instructions. file. The "variables" segment is then transmitted includ- 

Ifthe program is found as a result of the check made ing the name, current value, and relevant status of each 

in block 356, then parameters are constructed by the variable (406). Any certificates which were collected as 

program (364). Invoking external routines involves a part of performing digital (authorizing) signatures dur- 

P-code interrupt, with a possible rollout. This allows us 35 ing this or previous traversals are then transmitted, 

to conserve storage in multi-user swapping environ- Thus, any time a digital signature operation is per- 

ments if the external program is lengthy, or in any envi- formed, all the associated certificates are collected and 

ronment if the external routine is huge and therefore the transmitted in the certificate section of the travelling 

storage used by the travelling program should be va- program 408. The signatures are maintained as variables 

cated in order to satisfactorily perform the external 60 within the program (Le., within variable control 

program. In this case, the P-code interrupt is signaled in blocks). Certificates in the presently preferred embodi- 

biock 366. The indicated PRE-ROLLOUT routine ment are treated as material which can be accessed via 

copies the parameters to the external form the stack (or built in function calls. 

variables) to temporary storage. The ENTER-ROLL- Alternatively, it would be possible to include in the 

OUT routine invokes the EXTERNAL routine and 65 certificate package even those certificates which relate 

receives any returned result; and the POST- WAIT to the signatxires of the overall transmission and sig- 

routine copies the returned result to the stack (if the nature(s) which authenticate and authorize the program 

external routine was invoked as a function). itself. However, this would require that all the certifi- 
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cates definitely be known at the time tlie Certificate 
segment was written, and the logic, and possibly the 
position of the segments would need to be re-ordered to 
insure optimized processing. 

In our implementation, we prefer to keep the certifi- 5 
cates associated with the program's authorizing signa- 
ture with the program authorization information in the 
header or program segment, and the certificates for the 
user-to-user transmission signature authentication with 
the signature in the closure segment 10 

After, the certificates are transmitted, all file control 
blocks are examined resulting in the examination of all 
files which may have been transmitted during prior 
traversals and any newly attached files 410. A check is 
then made in block 412 to determine whether there are 15 
any more file control blocks to examine. A check is then 
made at block 414 to determine whether any file being 
examined was scheduled to be detached 414. If so, the 
routine branches back to 412 and neither the file, nor the 
file tag is copied for transmission. If the file is not sched- 20 
uled to be detached, then the file tag name is copied into 
the transmission 416. 

A check is then made to determine whether the file in 
question is part of an incoming travelling program 
which is being carried forward (418). If it is determined 25 
that it was part of the incoming traversal, then all file 
attributes from the incoming traversal as well as the file 
itself is copied to the outbound transmission file (422). 
This input file name may be accessed via the execution 
control area XCA and the input position of the file is 30 
associated with the fde control block 422. 

If the file is not part of an incoming traversal but 
rather was attached during the travelling program exe- 
cution, then the file, the file type, and its attributes are 
copied mto the transmission file 420. Thereafter, the 35 
routine branches back to block 412 to determine 
whether there are any more file control blocks to exam- 
ine until all file control blocks have been examined. 

As indicated in FIG. 21, when all FCB*s have been 
examined, a check is made to determine whether an 40 
overall user-to-user digital signature has been requested 
is required by the system program 430. Such an overall 
signature would be useful in detecting tampering with 
transmitted information. 

If an overall digital signature is to be taken, then a 45 
digital signature operation on the hash of all material 
transmitted is performed (432). The digital signature 
operation may be performed in accordance with the 
teachings of U.S. Pat No. 5,005,200 (or more conven- 
tional digital signature techniques which do not have 50 
the associated authority verification attributes, as de- 
sired). As indicated at block 432, a hash was previously 
taken for each part of the transmission. It is noted that 
alternatively, a hash may be taken of each of the hashes. 
The digital signature step may. involve user interaction 55 
to perform the signature. 

Thereafter, validation is supplied at the end of trans- 
mission as the "closure" segment. The validation is 
supplied by transmitting a hash reflecting prior mate- 
rial. The signed hash should demonstrate user-to-user 60 
authentication 434. Any certificate necessary to validate 
the final signature, which are not already in the certifi- 
cate segment; should be included in the CLOSURE 
segment Thereafter, the transmission is closed 436. 

Finally, in block 437. the value "1" which was previ- 65 
ously loaded onto the execution stack for the benefit of 
the transmitted program when it arrives at the recipient, 
is removed and replaced with the value "0**— which is 



360 

20 

returned to the current caller to allow it to distinguish 
itself. 

Because creating a digital signature typically involves 
user interaction — such as possibly selecting a certificate 
and opening the private key, or asking the user to oper- 
ate his digital signature token device— the material de- 
scribed in FIG. 20 and 21 will actually operate in the 
preferred embodiment as P-code interrupt routines. As 
an example, the TRAVERSE function code would 
trigger a P-code interrupt, in which the logic from 
blocks 399 to 430 would operate as a PRE-ROLLOUT 
routine, while the block at 432 might operate as a IN- 
TER-ROLLOUT routine since it may require the 
aforementioned user interaction. The blocks thereafter 
(434, etc) would operate as a POST-WAIT routine. 

The travelling program can be designed as desired to 
transmit itself numerous time during its execution to 
various recipients. In such multiple transmissions, the 
variables can be changed prior to each transmission as 
appropriate. In this fashion, the program in the position 
to do processing distinct for each recipient in a manner 
which is implementation dependent. 

FIG. 22 illustrates a sequence of operations for at- 
taching a file to the travelling program. The attach file 
routine responds to an identified file tag and an identi- 
fied file name. As indicated at block 440, a check is 
made to determine whether a file control block with the 
same tag exists. If so, then the previous file with the 
same tag is deleted 442. 

Thereafter, a check is made to determine whether the 
specified file name reflects an existing fde which is ac- 
cessible by the user. In this regard, the travelling pro- 
gram may be associated with program authorization 
information which defmes the range of operations 
which the program is able to perform, includmg the 
ability to access files. Such program authorization infor- 
mation will be checked to determine whether the file 
name is accessible. If the file name is not accessible by 
the user, then an error code/message is returned to the 
user 446. 

If the file name is accessible to the user, then a file 
control block (FCB) is built with the specified tag and 
file name and the file will be attached during the next 
and subsequent transmission of the travelling program 
448. The routine is thereafter resumed with an indica- 
tion that the file has been attached successfully. 

FIG. 23 illustrates how a file is erased from the user 
system. When an "erase" function is attempted to be 
executed, security codes are checked to determine 
whether the program is authorized to perform such an 
operation (450). If the security codes indicate that the 
program is authorized to erase the specified file (452), 
then an erase operation is performed and the routine 
branches back with an indication whether the fde was 
successfully erased 454. Alternatively, if the program is 
not authorized to perform an erase operation, then the 
calling routine is returned with an error message indi- 
cating that the file could not be erased (456). 

FIG. 24 illtistrates the sequence of operations per- 
formed in detaching a file from a travelling program. As 
indicated in block 458, a check is made to determine 
whether a file control block exists for the identified tag 
associated with the file to be detached. If no FCB exists, 
then the main routine is returned to with an error mes- 
sage indicating that the file could not be detached 462. 
If the fde control block does exist as determined at 458, 
then the fde control block is deleted at 460 and the main 
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routine is returned to with an indication tliat the fUe has preparation for receipt by the INTER-ROLLOUT 

been successfiilly detached. routine (shown in FIG. 27) which will perform the user 

FIG. 25 delineates the sequence of operations per- interactions associated with performing the actual sig- 

formed when a file is to be "exported", i.e., transformed nature. 

mto a user fUe. A travelling program may take a sped- 5 In block 512, the P-code routine is signalled, with 

tied file, for example, representing a spreadsheet and interrupt routines which are described below, 

convert such a file to a recipient user's file that remains if the digital signature authorization is authorized, 

with the user even after the travelling program has been then a display panel must be presented to the user to 

sent to a further destination. The file to be "exported" soUcit which certificate is to be used for the signature 

wiU be Identified by a tag and an output file name and, 10 operation. The signature operation is preferably per- 

ri '^'^^•^ '■^'^f'^ indicator identifying whether the fonned in accordance with the inventor's U.S. Pat No. 

tUe may be rewritten. . . „ 5.005.200 which patent has been expressly moorporated 

A check is mibaUy made as to whe&er a ffle control herein by reference. The user may possess a wide range 

Mock exKts for the specified^g 498. If no FCB exists, ^f certificates for performing digital signature opera- 

thoi an appropriate error mdicatmg code is generated 15 including those constructed along the lines of U.S. 

ana ine_cauing routme is retoned to (504). If a FCB p^^. No. 5,005,200. The INTER-ROLLOUT routine is 

does exist with the specified tag, a check is made to 3, w^^^ 509 after much of the storage is 

aeiermme wnemer ine lue is pan 01 an mconung travel- j^jj^ ^ signature routine itself must remain in 

ling program 500. If the fUe to be exported was not part 3^ of course). 

01 an mcommg traversal, then it must have been at- 20 ir 51 * * 1.1 r -r .t. 

t»r.u^^ K,. J t ^ 1. * • .1- , " there are no certificates suitable for performme the 

tached by the user and already be present m the user s • ^ *v -^1 ^ 1.1 1 

fiu , ^ i 7 J signature, then control passes to block 515 which gener- 

rne and, accordingly an error message is generated f' -j-^fu * ^ ^ ^1. - 

indicating that one^ not allowed to export a newly ates ^ error mdi<^tor to be retur^^^^ 

attached file 502. If the file was part of the mcoming ^'^^ ^ ^^^^ certificate suitable for perform- 

traversal, then a check is made to determine whether 25 ^^J^Vj^^^' automati^y passed to 

the specified file already exists (480). If so, then a check "Jf ® ^ ^JfJ"^}^^^^ certificates, 

is made at block 482 to determine whether it is okay to ^^'V' ^^""^ ? user decLnes 

rewrite the specified file. The check includes determin- ^ ^ appropnate error mdicator is gener- 

ing whether the program is aUowed to modify the speci. and passed to die program (515) Otherwise, the 

fied existing file (if no "overwriting"), or to erase and 30 suitable certificate is passed to (513). 

create the specified file (if "overwriting" is permitted). associated private key is then located (513). If 

If not, then the block 484 is used to return an access ^^^^ ^18 determines that it is located on the user's 

error to the program. If the check at 482 indicates that ^^^^ ®*®P (^^) ^ *^ communication 

it is okay to rewrite, a determination is made as to ^ perform the digital signature, 

whether the file should be overwritten or whether new 35 Otherwise, the user's private key is located in the sys- 

material should be addedito the end of the file (486). If ^^m encrypted under a secret password phrase. The 

overwriting is indicated at 486, then the existing file is soUcited (520) for this password, which is used to 

erased (488). A new file is created, if permitted by pro- decrypt the private key. Any errors or bad passwords 

gram authorizing security information and preparations detected, an appropriate error message is generated, 

are made to start writing at the beginning of the file 40 To inhibit guessing by someone other than the true user, 

(490). only a limited number of tries to give the correct pass- 

If overwriting is not indicated at 486, but new mate- word are allowed, 

rial data is to be added at the end. then preparations to block 522, the password is used to decrypt the 

start adding at the end of the existing file are made, as private key, which in turn is used to sign the message, 

indicated at block 492. Thereafter, the data is copied 45 according to the necessary authority. After the opera- 

from the correct position at the incoming traversal file traces of the secret material is erased, and the 

to the output file (494) and the main routine is re- signature and certificate are returned to (268, FIG. 15) 

entered with an indication that the exporting operation ^ temporary storage. In (270) control is then given to 

has been successfully performed (496). the POST-WAIT routine (530) which moves the signa- 

FIG. 26 illustrates an exemplary sequence of opera- 50 ture from temporary storage to the execution stack, 

tion performed when material is to be digitally signed. In block 532, the operation is checked, and if it was 

In implementing the digital signature function, initially successful, the proof hierarchy for the signer's certifi- 

a check is made to determine whether a digital signing cate is obtained. Certificates are added to the overall 

operation is permitted by the program as indicated at certificate collection (maintained in the XCA (90, et al)) 

block 510, Whether a program is permitted to perform 55 if they do not already appear. 

a digital signature operation will be controlled by pro- FIG. 28 illustrates the sequence of operations per- 
gram authorization information which is associated formed when displaying information to the user. The 
with the program and which is monitored every time travelling program has associated therewith a display 
the program is executed to ensure that unauthorized layout capability which is described in conjunction with 
operations are not performed.. If the digital signature 60 FIG. 28. The layout capabilities of the travelling pro- 
operation is not permitted, then an error message will be gram adapt functions heretofore associated with type- 
generated rejecting the digital signature function call setting appHcations for use in a user interactive display 
511. mode together with additional enhanced capabilities. 

If the digital signature operation is permitted then in The screen may be laid out such that input fields can 

block 514, the SIGN function prepares for user interac- 65 be readily moved and associated, with various attributes 

tion by moving an image of the data to be signed, to- for very flexibly interacting with the user. Various dis- 

gether with any parameters (such as any required autho- play related operations and functions are summarized in 

rization for the data content) to temporary storage in block 540. The display presents an output based on a 
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specified layout definition process controlled by the FIG. 29 delineates a sequence of operation performed 

display processing portion of the interpreter. by a time delay routine. The time delay function may be 

The display processing involves analy2dng condi- utilized to wake up at predetermined time intervals and 

tional attributes and static attributes for the fields and check to see whether any incoming electronic mail has 
the group of fields in the layout definition. In the display 5 arrived and attach itself to that mail to thereby effi- 

processing subroutine, variable substitution and itera- ciently handle incoming electronic data interchange, 

tion using conditional logic is performed as necessary. Thus, though such a time delay mechanism, a travelling 

Although variable substitution is permitted, the system program could examine a particular mail box at prede- 

retains association between an input variable and where termined time intervals to check whether any mail has 
the field is to be displayed on the screen in the corre- 10 arrived. If the mail has arrived, the travelling program 

sponding variable control block (VCB) even if the field could send the mail to a destination to be handled by a 

is flowed into its final output position as dictated by the further recipient. Alternatively, the travelling program 

layout definition. could examine incoming data (such as mail), and based 

The following attributes are then provided to each various content indicators, automatically perform a 

field including, color, font, boldface/italics, style, size, traverse and spawn a new "instance" of itself which 

underlining, blinking, revene video, non-display (e.g., could treat the mail appropriately. Of course, the origi- 

for hiding passwords), high intensity display, etc. Addi- "instance" could continue executing and process 

tionally, possible error messages are inserted where ^^^^ instance that arrives. 

appropriate for a detected error condition and the example, if the incoming information happened 

proper cursor position is indicated. transactions, then a travelling program could 

The layout language used in block 540 permits not information (using, for example, a READ built- 

only the definition of a screen output but also definitions function), break it apart into internal variables, deter- 

for accepting input. As indicated in block 542, fields are ^^^^ processed, and perform the 

written to the user's termmal allowing mput fields, as aPP^pnate traversal. Once successfuUy routed, the 

appropriate depending upon the appUcation. As previ- ^^"^^ ^"ff disposed, moved or archived, the pro- 

ously described, data structures may be rolled out to P^"^^ ""^^ vanables, and resume lookmg for 

auxiliary storage (544) and roUed back (546) after the more mput . ^ ^ • • .t. . 

user perfonns data entry into the appropriate input Alternatively, after^detenmmng the type of matenal 

^jgjjg *'r f f amved. It could mvoke another program to process the 

To do this, the step 544 actually involves signaling a i°^°^°g ^^^J^^l ^'""^ happened to be a 

P-code interrupt, and having the block 545 exf^ed^as T P^^?^ .^^^ ^'"'^ ""fn^.t ""^-^T 

the associated INTER.ROLLOUT routine, and block S^^^^pT^.^^P^* information, and could then TRA- 

iiAA jymc^ wrAiT ^ -Li VERSE Itself appropriate to the handlmg. 

546 executed as the POST-WAIT routine responsible in.'^ i j ii r i * «• 

f • - r- ij 1. 1 ^^^i'^"**"^*^' This would allow, for example, one travelling pro- 

for mappmg the mput fields back to the VCBs for the 35 ^ ^ ^^^^^ic roiter for incoming^ ckta, 

associated vanables. This may mvolve passmg data 3, ^j^j^ transactions, and then hand off to other 

through temporary storage. travelling programs the transactions which it is not 

Thereafter, the mput is analyzed and the mput data is prepared to handle itself, 

inserted m all ^ociated variable, A field vaKdation is Furthermore, if the EDI were signed, then the travel- 
then performed for all mput fields S4$. Thus a check 40 ling program could verify the signtture immediately. If 

may be made to make sure tl^t for numenc fields only ^^^^ especially if it were done 

numbers have been entered. Similarly, a check may be according to U.S. Pat. No. 5,005.200, then the authori- 

made to determme whether an mput field has the speci- nation for the content could be programmatically 

^^T^^ f**^' u 1 • J t_t 1 . . screened, and the travelling program could automati- 

Thereafter, a check is made at block 550 to determme 45 cally spm^fl^ an instance to handle the incoming trans- 

whether there has been an error m any field. If there has action. 

been an error, then an^error message is produced and por example, with proper enhanced authorization, an 

the cursor is positioned to the errant field (552). after incoming Purchase Order could be automaticaUy and 

which the routine branches back to 540 to generate an instantly routed to the shipping department to com- 
error message display. 50 jj^^nce filling 

If the check at 550 fails to reveal an error in a particu- items which arrived which were not signed, or which 

lar field, then a further check is performed to cross used simple signatures rather than authorizing signa- 

verify that the fields are correct in context (e.g., al- tures, could be routed to various clerical persons for 

though two adjacent fields may be correct individuaUy. exception processmg and more detailed inspection, 
an error condition may be defmed regarding the combi- 55 As indicated m block 570, the time delay routine, sets 

nation of fields) 554. Based on a cross verification, a the system alarm clock for a specified time. Thereafter, 

determination is made as to whether the field contains an optional roll out of data to auxiliary storage may be 

an contextual error. If not, then a return is made to the performed (572) by scheduling a P-code interrupt with 

caller 558. If there is a contextual error then an error, appropriate routines followed by a performance of a 
message is produced in accordance with block 552. 60 roll-in of data after the specified time period has 

It should be noted that verification of both the indi- elapsed. Thereafter, a return to the calling routine oc- 

vidual fields is completely under control of the pro- curs (576). 

gram. There may be various specifications, utihty rou- FIG. 30 which shows the sequence of operations for 
tines and other conveniences to simpUfying handling a "select from directory" function. The directory could 
common situations, but m general, any possible valida- 65 be a directory of files or a directory of user's, etc. Ini- 
tion is possible. Cross-validation of fields may involve tially, a list is created of all candidate items 580. There- 
more semantic concerns, and ^ is thus more likely to after, a display is generated to display at least part of the 
require speciahzed programming. list 582. The user will have an opportunity to select 
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among those items presented (583, 585), after which the (630). Thereafter, data is read from the specified file and 

function will return the names of the selected items, saved as program variables 632, FIG. 35 illustrates how 

either as a function result or a set of special variables the travelling program may update or create a file from 

^^)' . program variables. As indicated in block 640, the user 

Again, as described elsewhere, the actual WAIT is 5 file into which data is to be written is first determined, 
performed through the use of the P-code interrupt func- Thereafter, a function is invoked that writes program 
tion. In this case the INTER-ROLLOUT routine waits variables mto the user file 642. 
for the user to select from the selection, and returns the It should be understood, even if not e3q)licitly de- 
input to the program variables through the POST- scribed in every case, that any program function which . 
WAIT routine. 10 could lead to data loss, alteration, damage or disclosure 

FIG. 31 is a routine which demonstrates how the is subject to security controls. Such controls can be 

interpreter program permits a user to perform digital applied at the program level, and either be tied to the 

signatures. As indicated at block 600, the data to be incoming program and possibly by combmed in some 

digitally signed is assembled based on data which the predetermined fashion with those also imposed by the 

program is able to access: this includes user supplied 15 user. 

input, data read from files, data accumulated from pre- Therefore, for example, in the above case, the travel- 

vious traversals, data based on the user's environment ling program could only read or write user's data files if 

(e.g., the user's TSO identifier), the time, data incorpo- the program were so authorized. 

rated into the program itself, and data derived from Security constraints exist for at least the following . 

built-in functions (such as the built-m X12 data dictio- 20 classes of functions: 

nary). Appropriate information is displayed to the user 

(602). The user then decides whether he or she wishes Display data to the user, 

to sign the data, as mdicated.at block 604. If the user Soliciting input from the user, 

indicates he wishes to perform the signature, the system Performing digital signatures, 
invokes the sign function, as illustrated in FIG. 26, to 25 

further interact with the user and complete the signa- Reading data from user files, 

ture (606). Thereafter, the digital signature is generated Creating user files, 

and saved as a program variable 608. Erasing user files. 

FIG. 31 and the flowcharts which follow depict, in Writing data into user files, 
part, how a user might utilize the travelling program 30 Remaining user files, 
methodology described therein, while performing rela- 
tively few operations to accomplish powerful functions Attaching user files, 
built into the aforedescribed interpreter. Exporting attached files into user files, 

FIG. 32 exemplifies how a user would verify re- Invoking an digital notary device, 
ceived information. As indicated in block 610, the data 35 

which is expected to be verified are assembled. Thereaf- Receiving incoming electronic mail, 
ter, a "verify" ftmction with the assembled data and the Reading the contents of electronic mail, 
saved digital signature, together with any possible au- Moving or archiving incoming mail, 
thority requirements is invoked. The verification func- 
tion may be accomplished as described in U.S. Pat. No. 40 Deleting incoming mail 

5,005,200 or using standard digital signature techniques Generating outbound electronic mail, or doing vari- 

if a conventional digital signature operation was utilized ous types of data transmissions, 
to sign the variables. Thereafter, a determination is 

made based on the processing in block circuit 12 as to Bemg coupled to various types of equipment, device 

whether the si^aturc is verified (614), If so, then the 45 and services (FAX, printers, office equipment, robot 

program execution continues. If not, an error condition devices, manufacturing equipment, etc.) 
results indicating that the data has been tampered with 

or that there has been some kind of programming error Performing a program traversal, 

616. Return codes are defined to allow the program to Invoking external programs^ 

distinguish whether the signature was invalid, whether 50 Accessing, updating, activating, erasing, altering, 

it supported authorization capability, and if so, whether invoking, or attaching other travelling programs, 

the authorization was confirmed. 

FIG. 33 illustrates how a travelling program collects FIG. 36 is illustrates how a travelling program may 

a file to be transferred. Initially, the program determines be designed to be split and sent to a number of different 

the file to be transferred by, for example, displaymg to 55 recipients and FIG. 37 demonstrates how the previ- 

the user, a list of files 620. A check may be made to ously spUt programs may be merged, 

determine whether it is necessary to have user interac- . Turning first to FIG. 36, the travelling program may 

tion in order to determine the file (622). If yes, then the need to be split in order, for example, to acquire survey 

user is prompted to detennine the file to be transferred data from a number of different recipients or to collect 

624. If it is not necessary to have user interaction to 60 or distribute data to a number of different executives in 

determine the file, then the entire file contents are at- an organization. Initially, the travelling program per- 

tached to the set of data to be transferred 626. The forms various housekeeping operations to prepare to 

operation is accomplished using the attached functions split 650. Thereafter, variables are set m accordance 

set forth in FIG. 22 which involves building a file con- with particular application requirements, e.g., the sur- 

trol block as previously described. 65 vey run by a particular user 652. Destination users are 

FIG. 34 illustrates the travelling program operations then determmed and the traverse function is invoked as 

performed in reading data from a specified file. Initially per FIGS, 20 and 21 to transmit the image of the pro- 

the file is determined con tainin g the data to be read . grams, the programs variables together with any other 
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appropriate data tailored to the individual recipients is transmitted to the next destination 704. If all instances 

654. The transmitted variables may change from in- have not yet arrived, then a message is issued such as 

stance 1 (656) to instance 2 (658), instance 3 (660), to "waiting for forms to arrive" (702) and the routine is 

instance N (662). temporarily existed. 

A check is ultimately made to determine whether 5 FIG. 38 shows an alternative approach to merging 

there are more destinations to which to transmit (664). previously split travelling program . information. As 

If so, then the routine branches back to 652 to transmit shown in block 710, the ti^velling program arrives at a 

to the further destination. If there are no further destina- merging destination and is run. The collected data is 

uons, . then the final transfer is performed 666 in the then written to a special file 712. A check is made to 

same manner as explamed above with rapect to 654 to 10 determine whether all other instances have arrived as 

result m.the final instance" 668, thereafter resulting in indicated at 714. If so, tiien the collected data is pro- 

the completion of the sphttmg operation. messed 716, and the program traverses to the next desti- 

In other examples, it may also be tiiat ti« master „ation 718 and the routine is exited. If all other instances 

program simply goes mto sonie other processing. Per- h^^^e not arrived as determined at 714, then a message is 

S; Hilw^^fT^WK* ^''^ enviromnent as an 15 .^^^^ ^ ..^^^^^ for more forms to arrive" 

Z^l^r^ • • ' "V! ^'''^ l'*^^*^^ (720) and tiie current instance is deleted 722. and the 

hausted (havmg just been spun off to a number of users), routiie is exited 

" TnSf„ffn^t%1?^,r*" else arrived. piG. 39 is a flowchart indicating how the travelling 

lJZ^J^2!SSH^3S1^^cf^;^^f^ program has been designed to accommodate electronic 

ling program has the mtelligence to transfer itself from 20 j * • ... i_ ' rBr\?^ ^ ^- -i-^.-^ 

user to user to merge further data until the merging mterchange CEDI) generadon functions FIG 39 

operation is complete. InitiaUy, the travelling pro^ specifically demonstrates how a pardcid^ ^^12" 

arrives at a merging destination and is executed (SSoTa f"^'^^ characteristic may be used. The X12 standard 
check is made to determine whether this is a master dictionary and segment dictio- 

"instance" which is determined by a predetermined 25 ^ary. The X 12 segment dictionary, for example, may be 
variable being set. If it is determined tiiat this is not a *° ^^^i ^ segments ne<^sary to define a pur. 

master instance at 682, a slave instance is identified 684. ^^^^ segment is defined as being a piece of 

At (685) the slave program checks if it has been invoked ^^^^ ^ ^^^^ dictionary. Because 

witii the special "DEBRIEF' parameter (which is sim- ^^^^ are many different ways to specify the quantity of 
ply a convention used by this program ot determine 30 ^ variations of data are permitted in X12. 

when tixe slave is being called by the master), and if so present system embeds the X12 data dictionary 

(687) passes back all pertinent information to tiie master interpreter which may be called as a built-in 

instance, then exits. If this is not the DEBRIEF invoca- function. As indicated in block 720, initially a call is 
tion, then a check is made to determine whether the subroutine by specifying a segment 

master instance is available, i.e., has already arrived, 35 name and items "XX, YY, WW, The program can 
686. If the master instance is avaflable then a call is provide X12 data code for popular common options 
made to the master instance 696, through the use of the typical in the organization's environment, so as to build 
call shown in FIG. 18. After the master instance has a short list of options in order of normal usage. Exam- 
been invoked, the routine branches back to block 680. If P^cs of such items are, in a purchase order context, item 
the master is not available, a message is issued that the 40 number, part number and quantity. This call will result 
master control for the series has not arrived 688. in a call to the built in daU dictionary. 

Presuming the master instance has arrived and has ^ check is made to determine whether the short list is 
been invoked, then at block 682 a determination is made empty (as indicated in 724). If so, the segment name is 
that this is the master instance and a check will be made used to call the built-in function X12SEGLIST that 
to determine whether any other slave instances have 45 locates the segment dictionary table of all associated 
arrived 692. If so, then the slave instance will be in- data options 736. Thereafter, X12DATANAME built- 
voked with a predetermined parameter to initiate the in function would be used to expand the data dictionary 
collection of data (referred to perhaps as "debriefing") each associated description data 738 and the long com- 
694. At entry point E, data is collected from the m-. plete list would be displayed 740. 
stance and is returned to the master and is written to a 50 If the check at 724 mdicates that there is a short list, 
collection file 706. Thereafter, the instance that has just the X12DATANAME data dictionary is used to locate 
been invoked is erased 708 and the routine branches the expanded description of each of the options on the 
back to 692 in which case further information is col- short list. Thereafter, the short list is displayed 728. 
lected if other instances have arrived. Then, a check is made to determine whether the user 

If no further instances have arrived the file is checked 55 wants the full long list as indicated at 730. If the answer 
to see if all instances have all arrived (698). If they have, is yes, then block 736 is executed as described above. If 
as determined at 700, then the data could be read from no, then the user's selection from either the short list or 
the collection into variables in the travelling program. the long list is accepted (732). 

Depending on the expected size of the collection file, A check is then made at block 734 to determine 
and the nature of the processing, it might be more desir- 60 whether all data is collected. If so, we assemble and 
able for the master program to process the completed , emit the completed XI 2 transaction 742 and then exit 
file at that moment and either traverse itself to the next the routine. With respect to the emitting operation re- 
destination, or to encapsulate the result into a simple ferred to in conjunction with 742, the present invention 
message, perhaps even an EDI transaction and simply contemplates the capability of mailing specific sets of 
transmit that raw data. 65 X12 data in addition to mailing the entire travelling 

In other cases it might be appropriate for the program program. If all data is not collected as indicated by the 
to ATTACH the file to itself and transfer it wholesale check in 734, then more data items are retrieved and the 
to another process. The file is erased and aggregate data routine execution is repeated. 
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FIG. 40 relates to the use of the travelling program in the following listing reiterates and summarizes many 

receiving an electronic data interchange transaction. of the above-described functions (and identifies some 

For example, a particular user may have received a additional functions) which the preferred embodiment 

travelling program generated purchase order. Initially, is capable of performing. This list is only illustrative and 

the received EDI transaction is read 750. Perhaps by a 5 is not intended to be exhaustive of the many other appli- 

timer-delay travelling program, as described with FIG. cations to which the present invention may be advanta- 

29, which spawns copies of itself as input arrives. The geously applied, 
encoded EDI is then parsed into program variables 752. 

The received EDI is then moved to an archive reposi- Displaying data to the user usmg a layout language 

tory to preserve that which has been received for possi- 10 (similar to, e.g, TxX, or SCRIPT), 

ble audit. The segments are then processed via a cou- Soliciting input from the user using a layout-type 

pled segment dictionary 756. The segment rules associ- language ( similar to, e.g., TeX, or SCRIPT). 

ated with XI 2 are enforced which, for example, may 

relate to not having certain kinds of data in particular Performing digital signatures for data computed 

fields, 758. For each data item, the data dictionary asso- imder program control. 

dated with each segment is located 760. For a statement Verifying digital signatures based on data computer 

such as shown in 762 where DESC=X- under program control. 

12DATANAME (SEGCODE, DATA ITEM), this Handling co-signatures, possibly including routing 

statement will result in a call to the data dictionary to suggestions derived from the signer's certificates, 
get a meaningful description of the data item. The re- 

trieved meaningful description will be placed into a Reading data from user files, 

display variable resulting in, for example, a display of Creating user files, 

the purchase order in a purchase order format. All data Erasing user files, 

items are processed by branching back to block 762 and Writing data into user files, 

all segments are processed branchiog back to 756. Renaming user files. 

The preferred embodiment also allows access to a 

Digital Notary facility by providing built-in functions Receiving incoming electronic mail, 

which can access a digital notary, or notary device such Reading the contents of electronic mail, 

as described in inventor's U.S. Pat No. 5.001,752 Moving or archiving incoming mail 

(which is incorporated herein by reference), or other Deleting incoming mail, 

devices as well. Generating outbound electronic mail 

By allowing a travelling program to access such a 

facility, the travelling program is able to move data to a Coupling to and controlling an outbound FAX 

platform where the digital notary can be easily ac- 35 server. 

cessed, then using the built-in function to do so. This Coupling to and controlling a printer. 

allows notarization for important signatures, times- Generating a graphical image. 

tamps for in bound traffic, or for any other reason. Since Coupling to and controlling a device that can receive 

such notarization is strictly under control of the pro- and transmit audio signals. 

gram, any criteria whatever, whether automatic or 4Q Accessing various types of equipment, including of- 

based on user requests, can be used. fice equipment, computer equipment (tapes, disks, etc.) 

Also as described earlier, the facility allows for the robot devices, manufacturing equipment, etc. 
coupling to outbound FAX so that electronic forms, in 

addition to being converted to EDI, or printed, can also Splitting an mstance of the travelling program into 

be faxed to the ultimate recipient. 45 several instances by virtue of multiple traversals. 

Also, as implied, but not explicitly stated, even when Being able to re-combine the data contained in the 
a travelling program emits an EDI transaction, it may several travelling programs, possibly not even reflect- 
still be activated later. One example would be a travel- ing the same program, into a single form, 
ling program which first serves as an electronic requisi- Erasing other instances of travelling programs, 
tion then, after sufficient approving signatures, gener- 50 Invoking external programs, 
ates a purchase order. It could then send itself to a Invoking other travelling programs as subroutines, 
repository where it could later be reactivated when the Activating other travelling programs as indepen- 
corresponding invoice and bills eventually arrive (elec- dently executing functions. 

tronic or otherwise) and can serve as a method for Extracting data from a dormant (non-executing) trav- 

reconciling the order with the shipment received and 55 ellmg program. 

the billing. It can incorporate logic which to keep track Determining information about another (non-execut- 

of which items have been received, and which arc still ing) travelling program without have to execute it 

pending. Because of the ability to flexibly direct itself, it such as name of the program, and other status, etc. 
can span many different sites. Insofar as handling ship- 

piiig and receiving, it is also possible to couple the trav- 60 Extracting information from the certificates associ- 

elling program with a bar code reader and validate ated with digital signatures. This information being used 

materials sent and received without human data entry. to help direct routing if cosignature requirements are 

The preferred embodiment envisions that the travel- involved, 
ling program could be coupled to a variety of equip- 
ment, including office equipment, and other devices and 65 Making a copy of a travelling program as a data 
facilitates. variable within another program, or ATTACHing a 

Also, any given traversal could also be sent simulta- travelling program as a fde to another, 
neously to a variety of recipients. 
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Using one travelling program (the "carrier") to trans- quence of digital instructions must be further trans- 
port a new version of another to various destinations, mitted. 

and replacmg the program segment of existing instances 2. A method according to claim 1, wherein said digi- 

with another, more up-to-date version of the program. tal signature is included as part of the accompanying 

One way to do this would be for the newer program 5 data to the next destination. 

segment to be added to the end of existing travelling 3. In a digital communications system having a plural- 
programs. Enhancements to the existing interpreter/- ity of computers coupled to a channel over which corn- 
loader would recognize that a program segment follow- puters exchange messages, a method for processing 
ing the closure segment reflected a suggested program information among said computers comprising the step 
revision- After whatever normal transmission was per- 10 

formed,- it would then validate the digital signatures executing on a first computer a sequence of digital 

associated with the proposed revised program, and, if instructions, including instructions which deter- 

they carried the proper authority, would then com- Jiane at least one next destination that receives the 

mence using the new program in place of the program sequence of digital instructions together with ac- 

which had arrived as part of the standard traversal. companying data including at least one digital sig- 
nature; 

Attaching user files. transmitting said sequence of digital instructions to- 
Exporting attached files into user files. gether with said accompanying data to said next 
Detaching previously attached files. destination; 

20 performing, under the control of said sequence of 

Accessing a digital notary device. digital instructions, a digital signature verification 

Performing a program traversal. operation based upon information contained in said 

Transmitting user data (in other than a traversal), so accompanying data; and 

that the transmission does not include the travelling determmmg, at said next destmation whether the 

program itself, (e.g., simply sending a message to an- sequence of digital instructions must be further 

other destination. transmitted. 

4. A method according to claim 1, wherein said digi- 

Using built-in functions to simplify the use, creation, f .signature is represented as data subject to being 

display, construction and receipt of EDI (such as X12 '^""f^ processed by said sequence of program m- 

or EDIFACT) to conveniently supply common mfor- ^ c^A°'^'*t. j . i - r . , 

mation and facflities without havtog to supply these J' f ^ofOTdmg to daun further mcluding 

functions in the travelling program. TOs includ^ bu^ f ^ °^ f 8 ^ digita^ certifiwte with said 

in functions which access the Data Element Diction^!, ^^''^ T^'^a f** y!^^:^"":^^ digital certificate's 

the Segment Dictionary, the segment S ^dT^ „ «P^««ted as data subject to bem^ 

transaction sets themsdik V a mS^. ^^^7 r^^^T • . ^- • 

0. A method accordmg to claim 1, wherem said digi- 

xTFi,;!^ .u^i u«„ J u J • ^ *al signature is included as part of said accompanying 

„,i5^hiJ^f. T ^ '^^^1'°*'°'""'''^^ data transmitted to the next destination. ^ 
^^Jho^iLT^frK. H ''I '°J'fwT°'' ^'T' ^- A method according to claim 1, fiirther including 
fnT^^;^Tf^^T r^.°^ ttat he invention 40 the step of acquiring dati from a user at at least one of 
^».^o„nt,/J^-^ to the disclosed embodimen^ bu on computers, translating the acquired 

die contrary, is mtended to coyer various modifications data by said sequence of digital progrin instructions 
and equivalent arrangements included withm tiie spirit i„to a fredefmed data struct^e confo^g to a recog- 
andsoope of the appended clauns. nized standard. 

What is claimed is: 45 j. A method according to claim 7, fiirther including 

1 In acommumcations system havmg a plurahty of the step of processing and verifying the digital signature 
digital computers coupled to a chamid over which ^nd the dat^ to which it is appuSuidependently of said 
computers exchange digital messages, a method for sequence of digital instructions, 
processing mfomatoon among said computers compris- 9. a method according to claim 1, fiirther including 
mg the steps of: 50 translating data under direction of the se- 

executmg on a first con^juter a sequence of digital quence of digital instructions into an Electronic Data 
program mstrucUons mcludmg instructions which Interchange (EDI) format 

determine at least one next destination that receives lo. A method according to claim 1, including the step 
the sequence of mstructions of logicaUy constructing the information to which the 

transmittmg to said next destmation, digital informa- 55 digital signature can be selectively appUed, wherein 
tion compnsmg at least said sequence of digital such information is treated as a program variable on 
instructions and accompanymg digital data associ- which the sequence of digital program instructions 
ated with said sequence of digital instructions; operate. 

determining, based on the sequence of instructions, at 11, a method according to claim 1, further including 
at least one of said plurality of digital computers, a 60 the step of performing a digital signature operation as a 
first digital valu^ function which is invoked under control of said se- 

computing, based on the sequence of digital instruc- quence of digital program mstructions.. 
tions, at at least one of said plurality of digital com- 12. A method according to claim 11, wherein the data 
puters a digital signature on said first digital value, supplied to said digital signature function reflects values 
thereby creating a digital signature value to be part 65 based on any one of a set of data read from a user's file, 
of said accompanying digital data; and data built in to said sequence of digital program instruc- 

determining, at said next destination, based on the tions, data entered by the user, data obtained from other 
sequence of digital instructions, whether the se- signatures, and data obtained from a digital certificate. 
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13. A method according to claim 1 further including 
the step of including an indication of the authority 
which has been vested in a user performing a digitai 
signatxire, by including sufficient digital information to 
allow verification that the authority exercised by the 5 
signer was properly exercised. 

14. A method according to claim 1 further including 
the step of selecting from a collection of digital certifi- 
cates the certificate to be used in performing a digital 
signature. 10 

15. In^a communication system having a plurality of 
computers coupled to a channel over which computers 
exchange messages, a method for processing informa- 
tion among said computers comprising the steps of: 

executing on a first computer a sequence of digital 
instructions, including digital mstructions which 
determine at least one next destination that receives 
the sequence of digital instructions; 

acquiring data from a user of at lest one of said com- 
puters under the control of said sequence of digital 
instructions; 

translating said data under the control of said se- 
quence of digital instructions into a predefined data 
structure; 

digitally signing at least part of said data structure via 
the execution of said sequence of digital instruc- 
tions to create a digital signature value; 

transmitting digital information including said digital 
signature value to a next destination under the 
control of said sequence of digital instructions and 
determining, at said next destmation» based of the 
sequence of digital instructions, whether the se- 
quence of digital instructions must be further trans- 
mitted. j5 

16. A method accordmg to claim 15, wherein said 
translating step includes the step of translating said data 
under control of said sequence of instructions into an 
Electronic Data Interchange (EDI) format. 

17. A method according to claim 15, wherein at least 40 
part of the aggregate of said data structure together 
with the digital signature of said data structure is trans- 
mitted as a set of data independently of the sequence of 
digital instructions. 

18. A method according to claim 15, wherein the 45 
result of the digital signature is verified when the set of 
instructions is executed at at least one subsequent desti- 
nation. 

19. In a communication system having a plurality of 
computers coupled to a channel over which computers 50 
exchange messages, a method for processing informa- 
tion among said computers comprising the steps of: 

executing on a first computer a sequence of digital 
program instructions, including instructions which 
determine at least one next destination that receives 55 
the sequence of digital instructions; 
' performing a digital signature operation under the 
control of said sequence of program instructions 
using a private key stored in a user token device to 
obtain a digital signature value; 60 

transmitting digital information including said digital 
signature value to a next destination; and 

determining, at said next destination, based on the 
sequence of digital program instructions, whether 
the sequence of digitai instructions must be further 65 
transmitted. 

20. A method according to cjiaim 19 wherein the step 
of performing a digital signature operation includes the 
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step of determining whether the user's private key is 
stored in a token device or in computer memory. 

21. In a digital communications system having a plu* 
rality of computer terminals which are located at a 
plurality of destinations and are coupled to a channel 
over which computer terminals exchange messages, a 
method for processing digital information comprising 
the steps of: 

executing on a first computer a sequence of digital 
program instructions, including instructions which 
determine at least one next destination that receives 
the sequence of digital program instructions; 

computing a digital value, the content of which is 
based on logical decisions and manipulations con- 
trolled by said sequence of digital program instruc- 
tions; 

performing a digital signature operation on said digi- 
tal value to create a digital signature value; 

transmitting digital information including said digital 
signature value to a next destination; and 

determining, at said next destination, based on said 
sequence of instructions whether tiie sequence of 
digital program instructions must be further trans- 
mitted. 

22. A digital data processing system for processing 
digital information by a plurality of computers coupled 
to a channel over which computers located at a plural- 
ity of destinations exchange digital messages compris- 
ing: 

a first computer including: 

at lest one memory for storing a sequence of digital 
program instructions including 1) instructions 
which determine at least one next destination for 
receiving said sequence of instructions together 
with accompanying data and 2) instructions for 
logically constructing digital data to be signed and 
for selectively performing a digital signature opera- 
tion on said digital data, and 

processing means for executing said sequence of digi- 
tal program instructions and for transmitting said 
sequence of digital program instructions to said 
next destination; and 

a second computer including: 

a memory for receiving and for storing the received 
sequence of digital program instructions and ac- 
companying data transmitted from said first com- 
puter including 1) instructions which determine 
any next destination for transmitting said sequence 
of instructions together with its accompanying 
data, and 2) instructions for logically constructing 
digital data to be signed, and for selectively per- 
forming a digital signature operation on said digital 
data, and 

processing means for executing said received se- 
quence of digital program instructions to thereby 
determine any next destination for said sequence of 
digital instructions. 

23. A system according to claim 22, wherein said 
processing means includes means for acquiring data 
from a user at at least one of said plurality of computers, 
and 

means for translating the acquired data by said se- 
quence of program instructions into a predefined 
data structure conforming to a recognized stan- 
dard. 

24. In a commimications system having at least one 
digital computer and a plurality of destinations within 
said communications system at which users perform 
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digital signatures, a method for handling digital signa- 
tures comprising the steps of; 
providing a sequence of digital instructions to control 
the management of digital signatures, including 
instructions which: 5 
determine digital values, 

control creation of a digital signature value based 
on determined digital values, and 

determine a next destination; 
executing in at least one digital computer at least one 10 

of said instructions to determine a first digital value 

to be digitally signed; 
executing in at least one digital computer at lest one 

of said instructions to control the creation of a 

digital signature value computed on said first digi- 15 

tal valu^ 
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executing in at least one digital computer at least one 
of said instructions to determine a next destination; 

transmitting to said next destination digital informa- 
tion including said sequence of digital instructions; 

executing in at least one of said computers at least one 
of said instructions to determine a further next 
destination; and 

transmitting to said further next destination, digital 
information including said digital signature value. 

25. A method according to claim 24, wherein said 
information transmitted to said further next destination 
does not include said sequence of digital instructions. 

26. A method according to claim 24, wherein each of 
said plurality of destinations includes a digital com- 
puter. 
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